Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

separate module context for Compiler.jl tests #56636

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

separate module context for Compiler.jl tests #56636

wants to merge 1 commit into from

Conversation

aviatesk
Copy link
Member

xref: #56632 (review)

This also allows us to execute each file standalone, which might be useful for debugging.

@KristofferC
Copy link
Member

Also need an InteractiveUtils.@activate in every file? And maybe that shouldn't double run on the same worker (in case the tests are executed in parallel in the future).

@aviatesk
Copy link
Member Author

When these files are run from test/runtests.jl, we usually want to test Base.Compiler, and in that case, we shouldn't call @activate Compiler. I think the current situation is just fine, where we only have @activate Compiler in Compiler/test/runtests.jl, which is an entry point to test Compiler.jl as the standard library.

@KristofferC
Copy link
Member

where we only have @activate Compiler in Compiler/test/runtests.jl, which is an entry point to test Compiler.jl as the standard library.

Okay but in the future, we will likely run these tests in parallel on different workers and each of these workers needs to run the @activate command (I presume).
So that's why I was thinking something like

julia/test/combinatorics.jl

Line 5 in 0ded536

isdefined(Main, :ImmutableArrays) || @eval Main include("testhelpers/ImmutableArrays.jl")
would be needed in all files because we do not know what files will run on what worker and in what order they will run.

But could be a later thing to add.

@aviatesk
Copy link
Member Author

Yes, it’s probably related to parallel execution, so it might be a good idea to revisit this discussion in a PR that enables parallel execution for Compiler.jl/test/runtests.jl.

@aviatesk aviatesk mentioned this pull request Nov 21, 2024
Merged
@aviatesk aviatesk force-pushed the avi/separate-compiler-test-context branch from 65d4b1b to b4acc79 Compare November 21, 2024 16:10
@aviatesk aviatesk force-pushed the avi/separate-compiler-test-context branch from b4acc79 to a150de9 Compare November 21, 2024 16:31
Keno
Keno requested changes Nov 21, 2024
View reviewed changes
Copy link
Member

@Keno Keno left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm ok with the setup_compiler change. For the module wrapping though, the Base test infrastructure does that internally, so I'm not sure it will be required once we switch to that (which we need to for parallel execution).

Base automatically changed from kf/compilertests to master November 21, 2024 22:21
@aviatesk aviatesk force-pushed the avi/separate-compiler-test-context branch 4 times, most recently from dc105dc to 700c2ac Compare November 22, 2024 05:57
aviatesk added a commit that referenced this pull request Nov 22, 2024
@aviatesk
complete the tests for Compiler.jl as the stdlib.
5f2dd1b 
With #56632, Compiler.jl as the stdlib can now be tested.
However, the PR was incomplete, and when tests are actually run on
`Compiler`, which is `!== Base.Compiler`, various errors occur,
including issues caused by #56647.

This commit resolves all these issues:
- manage the code for loading `Compiler` in `setup_Compiler.jl`,
  ensuring that the stdlib version of `Compiler` is loaded when
  `@activate Compiler` is used beforehand
- replace `Base.IRShow` with `Compiler.IRShow`
- test `Base.Compiler.return_type` instead of `Compiler.return_type`

This was split off from #56636.
@aviatesk aviatesk mentioned this pull request Nov 22, 2024
Merged
aviatesk added a commit that referenced this pull request Nov 22, 2024
@aviatesk
complete the tests for Compiler.jl as the stdlib.
c68bff0 
With #56632, Compiler.jl as the stdlib can now be tested.
However, the PR was incomplete, and when tests are actually run on
`Compiler`, which is `!== Base.Compiler`, various errors occur,
including issues caused by #56647.

This commit resolves all these issues:
- manage the code for loading `Compiler` in `setup_Compiler.jl`,
  ensuring that the stdlib version of `Compiler` is loaded when
  `@activate Compiler` is used beforehand
- replace `Base.IRShow` with `Compiler.IRShow`
- test `Base.Compiler.return_type` instead of `Compiler.return_type`

This was split off from #56636.
aviatesk added a commit that referenced this pull request Nov 22, 2024
@aviatesk
complete the tests for Compiler.jl as the stdlib. (#56648)
215189e 
With #56632, Compiler.jl as the stdlib can now be tested.
However, the PR was incomplete, and when tests are actually run on
`Compiler`, which is `!== Base.Compiler`, various errors occur,
including issues caused by #56647.

This commit resolves all these issues:
- manage the code for loading `Compiler` in `setup_Compiler.jl`,
ensuring that the stdlib version of `Compiler` is loaded when `@activate
Compiler` is used beforehand
- replace `Base.IRShow` with `Compiler.IRShow`
- test `Base.Compiler.return_type` instead of `Compiler.return_type`

This was split off from #56636.
@aviatesk
separate module context for Compiler.jl tests
79b6db1 
xref: <#56632 (review)>

This also allows us to execute each file standalone, which might be
useful for debugging.
@aviatesk aviatesk force-pushed the avi/separate-compiler-test-context branch from 700c2ac to 79b6db1 Compare November 22, 2024 08:44
@aviatesk
Copy link
Member Author

For the module wrapping though, the Base test infrastructure does that internally, so I'm not sure it will be required once we switch to that (which we need to for parallel execution).

That’s true; this is unnecessary as long as we go through the Base test infrastructure. Having said that, I think there might be situations where we want to run a single test file. By clearly separating the module contexts, we’d be able to repeatedly include("Compiler/test/inference.jl"), which I think has its value?

@aviatesk
Copy link
Member Author

Now this PR only includes module-wrapping changes only.

@Keno
Copy link
Member

Keno commented Nov 22, 2024

I tend to find the extra wrapping a little annoying for that use case, because I usually just want to play with the global scope variables directly in the REPL, but that's not a strong opinion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@Keno Keno Keno requested changes

Requested changes must be addressed to merge this pull request.

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@aviatesk @KristofferC @Keno